|
|
|
|
|
|
|
nonbelievers are usually new to the methodology or have never given thought to the historical problems of the software development process. Unfortunately, many of these programmers hail from the Visual Basic camp because Visual Basic makes development work seem deceptively simple and straightforward (thanks, Microsoft Visual Basic marketing staff). However, it must be stressed time and time again that the design phase is absolutely critical to the development of high quality software. Incorporating object-oriented design principles in your development efforts will pay off in the long run in the following ways: |
|
|
|
|
|
|
|
|
Lower project costs on average |
|
|
|
|
|
|
|
|
Greater respect for your productive abilities among peers and managers |
|
|
|
|
|
|
|
|
This chapter helps you on your way toward these ends. |
|
|
|
|
|
|
|
|
Using object-oriented design helps you identify classes and objects you've discovered in the analysis phase, as well as those not yet discovered. During design, you also elaborate on the architecture of the system, including the identification of possible design patterns and frameworks. Design patterns, in simple terms, are repeated ways that objects communicate with each other to carry out a system goal. Keep in mind that patterns occur in everyday life outside the computer programming industry. |
|
|
|
|
|
|
|
|
Note
Although I discuss design patterns in the last section of this chapter, there isn't enough time to cover all the design patterns discovered thus far. For information on the Internet, find http://hillside.net/patterns/. It's mainly for C++, but some patterns can be translated for Visual Basic. Also, browse to www.samsona.com (the Object Technology link) for more design patterns adapted to Visual Basic. |
|
|
|
|
|
|
|
|
|
When you finish the last design iteration (there can be many iterations through the design phase, depending on the complexity of your proposed system), your system specification will be detailed enough for you to develop the system without having to make assumptions about the system architecture or user motivations. The problems discovered during the actual development phase should be minor and should require minor iterations through the design phase to update the corresponding models. At the same time, minor updates in design models should lead to very minor updates in the analysis modelssuch as changes in the name of a class or class member or the addition of an argument to a private method. Major changessuch as drastic changes in the way objects communicate, the addition of a new subsystem or package, changes to the graphical user interface |
|
|
|
|
|